


(fcASA-TH-8S375) GEhEEAL CEJICI-CBIESIED N87-23190 

ECFIkAfiE CEVEICteiM (KASA) S7 p Avail: 

Alls EC A05/EE A01; single ccpies 

available ircK ltA£A/6£iC, Cede £52, Onclas 

Gceentelt, Bd. 2C771 CSC! 09B G3/61 0076838 



SOFTWARE ENGINEERING LABORATORY SERIES 


SEL-86-002 


GENERAL OBJECT-ORIENTED 
SOFTWARE DEVELOPMENT 


AUGUST 1986 



FOREWORD 


The Software Enqineering Laboratory (SEL) is an organization 
sponsored by the National Aeronautics and Space Administra- 
tion/Goddard Space Flight Center (NASA/GSFC) and created for 
the purpose of investigating the effectiveness of software 
engineering technologies when applied to the development of 
applications software. The SEL was created in 1977 and has 
three primary organizational members: 

NASA/GSFC (Systems Development and Analysis Branch) 

The University of Maryland (Computer Sciences Department) 
Computer Sciences Corporation (Flight Systems Operation) 

The goals of the SEL are (1) to understand the software de- 
velopment process in the GSFC environment; (2) to measure 
the effect of various methodologies, tools, and models on 
this process; and (3) to identify and then to apply success- 
ful development practices. The activities, findings, and 
recommendations of the SEL are recorded in the Software En- 
gineering Laboratory Series, a continuing series of reports 
that includes this document. 

The primary contributors to this document are 

Ed Seidewitz (Goddard Space Flight Center) 

Mike Stark (Goddard Space Flight Center) 

Single copies of this document can be obtained by writing to 

Frank E. McGarry 
Code 552 
NASA/GSFC 

Greenbelt, Maryland 20771 
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ABSTRACT 


Object-oriented desiqn techniques are qaininq increasinq 
popularity for use with the Ada proqramininq lanquaqe. This 
report describes a qeneral approach to object-oriented de- 
siqn which synthesizes the principles of previous object- 
oriented methods into a unified framework. Further, this 
approach fits into the overall software life-cycle, provid- 
ina transitions from specification to desiqn and from desian 
to code. It therefore provides the basis for a qeneral 
object-oriented development methodoloqy. 
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SECTION 1 - INTRODUCTION 


An "object" is an abstract software model of a problem domain 
entity. Objects are packages of both data and operations on 
that data [Goldberg 83, Booch 83]. The Ada^ package con- 
struct is representative of this general notion of an object. 
"Object-oriented design" is the technique of using objects 
as the basic unit of modularity in system design. The Soft- 
ware Engineering Laboratory at the Goddard Space Flight Cen- 
ter is currently involved in a pilot project to develop a 
satellite dynamics simulator in Ada (approximately 
40,000 statements) using object-oriented methods [Agresti 86, 
Nelson 86]. Several authors have applied object-oriented 
concepts to Ada (e.g., [Booch 83, Cherry 85b]). These meth- 
ods are useful, but limited when considered as a general 
approach to developing large software systems [Nelson 86]. 

As a result we have synthesized a more general approach which 
allows a designer to apply powerful, object-oriented prin- 
ciples to a wide range of applications and at all stages of 
software development. This report describes our approach 
and considers how object-oriented design fits into the over- 
all software life-cycle. 

The present report supercedes and expands our earlier work 
on this topic [Seidewitz 85a, Seidewitz 85b, Seidewitz 86, 
Stark 86], However, our work is still in progress and future 
versions of this document will include material on object- 
oriented specification and testing. 


^Ada is a trademark of the U.S. Government (Ada Joint Pro- 
gram Office) . 
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SECTION 2 - PROCEDURES AND OBJECTS 


In object-oriented desian, the basic unit of modularity is 
the object rather than the procedure. While a procedure 
defines a specific operation, an object defines a "state 
machine" with internal memory and multiple operations on 
that memory. This section discusses the concepts of objects 
and procedures and shows the relationship between them. 

2.1 PROCEDURES 

We beqin with the more familiar concept of' a procedure. We 
can model a procedure as a mathematical function. Fiqure 2-1 
shows one possible diaqram for representinq such a function. 
In this diaqram, the arrows represent data flows into and 
out of the procedure. However, in a computer proqram, there 
is a flow of control as well as data. Thus, when a proce- 
dure is called, we can' say that control "flows into" the 
procedure. When the procedure is complete, control returns 
to the caller. 


ARGUMENTS 


RESULTS 

GLOBAL DATA 

PROCEDURE 

GLOBAL UPDATES 

^ 





Fiqure 2-1. Procedure Data Flow 

The diaqram in Fiqure 2-2 shows both the data flow and the 
control flow. The arrow from CALLER into PROCEDURE indicates 
that CALLER transfers control to PROCEDURE. Note that the 
return of control to CALLER is not explicitly shown, but is 
assumed to happen when PROCEDURE is finished. The smaller 
arrows alonq the larqer control flow arrows show the data 
flows (similar to [Yourdon 79]), which may qo in either 
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direction alonq a control path. Also notice that in Fig- 
ure 2-2 we have added an explicit symbol for the GLOBAL DATA. 
Although control never really flows into data, we show 
access to such data symbols by arrows always directed toward 
the data. This indicates that the data is always passive 
and never initiates any action. 



Figure 2-2. A Procedure Call, With Data Flows 

When there are several control paths on a diagram, each with 
several data flows, showing all data flows can become cumber- 
some. Therefore, instead of explicitly showing the data 
flow on the diagrams, we include the data flow in a separate 
"operation definition" which describes the operation provided 
by the procedure. Figure 2-3 shows the diagram of Figure 2-2 
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redrawn without the data flow arrows. The operation defini- 
tion for the procedure in Fiqure 2-3 would be; 

PROCEDURE (ARGUMENTS) RESULTS 



Fiqure 2-3. A Procedure Call, Without Data Flows 

In the operation definition, the parenthesized data flows 
with the control flow, while the unparenthesized data flows 
aqainst the control flow. A qeneral operation thus includes 
two data flows. However, some operations have only one data 
flow, which may be in either direction relative to the con- 
trol flow. In fact, some operations simply siqnal an action 
with no data flow at all. Such operations have definitions 
of the form: 

RESET ( ) 
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The parentheses are included even when they are empty. For 
data symbols such as GLOBAL DATA in Figure 2-3, the control 
arrows implicitly define the appropriate data flows with no 
need for operation definitions. 

2 . 2 OBJECTS 

Whatever the notation, we still model a procedure as a math- 
ematical function. That is, given a certain set of inputs 
(arguments and global data), a procedure always produces the 
s ame set of outputs (results and global updates) . A proce- 
dure, for example, cannot directly model an address book, 
because an address book has m emory (a set of addresses) which 
can be accessed and updated. Normally, the solution to this 
is to place this memory in global variables, leaving it ex- 
posed to illicit modification. 

An object, on the other hand, packages some memory along 
with all allowable operations on it. We can model an object 
as a mathematical "state machine" with some internal state 
which can be accessed and modified by a limited number of 
mathematical functions. We thus implement an object as a 
packaged set of procedures and internal data, as shown in 
Figure 2-4. For an address book object, the internal memory 
would be a set of addresses, and the allowable operations 
would be accessing an address by name, adding a new address, 
etc . 

Internally, the procedures in an object are functions of 
both arguments and the internal memory. Externally, how- 
ever, an object appears as a "black box" with operations on 
certain arguments producing certain results. Now, though, 
the same arguments may produce different results at dif- 
ferent times, depending on the hidden internal state. An 
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"object description" includes a list of definitions for each 
of the operations provided by the object. For example: 


ADDRESS-BOOK 

Provides 


ADD (NAME + ADDRESS) 
CHANGE (NAME + ADDRESS) 
LOOKUP (NAME) ADDRESS 
REMOVE (NAME) 

OBJECT OPERATIONS . 


PRCXJl 


PROC2 


PROC3 


INTERNAL 
STATE DATA 


Figure 2-4. An Object 











An object can also represent a "type manager." a "type" is 
basically a template for a set of objects which all allow 
the same operations. The "type manager" object combines in 
its own state one complete state for each object of the type. 
Each type operation is then augmented with a data item which 
selects the specific object (state) to be operated on. For 
example, we could define a type manager which would allow 
creation of an arbitrary number of address books. The new 
object definition would be: 

address-book-manager 

Provides : 

ADD (ADDRESS-BOOK + ADDRESS + NAME) 

CHANGE (ADDRESS-BOOK + ADDRESS + NAME) 

LOOKUP (ADDRESS-BOOK + NAME) ADDRESS 

REMOVE (ADDRESS -BOOK + NAME) 

CREATE 0 ADDRESS-BOOK 

The new data item ADDRESS-BOOK must be specified for each 
address book operation, and the new operation CREATE returns 
a new, empty ADDRESS-BOOK. 
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SECTIOIM 3 


OBJECT DlAGRAi4S 


In this section we will connect objects into "object dia- 
grams" which represent system designs. Operations must take 
place between two objects, with control flowing from one to 
the other. Such a connection of two objects is called a 
"communication." In a communication, control flows out of 
one object to "invoke" an operation. The object which re- 
ceives the flow of control then "services" this operation. 
The point of an object diagram is to show all possible com- 
munications in a system. 

3.1 NOTATION 

As an example, consider a simple schedule organizer that 
consists of three objects; a USER INTERFACE, an ADDRESS 
BOOK and a DATE BOOK. Figure 3-1 shows a possible object 
diagram for this system. The round-cornereo squares in Fig- 
ure 3-1 represent objects. The arrows between objects rep- 
resent communications. Note, however, that each arrow can 
represent a call on one or more operations provided by the 
object to which it points. For each arrow leaving an ob- 
ject, we add to that object's description a list of opera- 
tions used from the other object. For example, the object 
descriptions for the objects in Figure 3-1 are; 

USER- INTERFACE 
Provides ; 

RUN ( ) 

Uses ; 

TERMINAL 

GET 

PUT 
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DATE-BOOK 


Provides : 

GET-APPOINTMENT (DATE + TIME) NAME + ADDRESS 
MAKE- APPOINTMENT (DATE + TIME + NAME) 

CANCEL- APPOINTMENT (DATE + TIME) 


Uses : 


ADDRESS -BOOK 
LOOKUP 


ADDRESS-BOOK 

Provides ; 

ADD (NAME + ADDRESS) 

CHANGE (NAl'lE + ADDRESS) 

LOOKUP (NAME) ADDRESS 
REMOVE (NAME) 

The user communicates with this system through the USER 
INTERFACE object. The system allows the user to store and 
retrieve addresses in ADDRESS BOOK. The user can also 
schedule appointments in his DATE BOOK with people he knows. 
When the user requests to see what appointment is scheduled 
at a certain time, DATE BOOK also automatically retrieves 
the address of the person to be met. The object diagram 
shows all the communications necessary to perform these func- 
tions. It thus defines the objects needed in tne system and 
all the interactions between these objects. 

In the above example, it is fairly easy to see that the "main 
control" object is USER INTERFACE. The only operation serv- 
iced by USER INTERFACE is the operation RUN. This operation 
is used to invoke the system, passing control into USER 
INTERFACE. USER INTERFACE then passes control to the other 
objects as necessary to perform the functions of the system. 
Thus all the other control flows are out of USER INTERFACE. 
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By convention, the arrow representinq the initial flow of 
control into a system is labeled "RUN” on an object diagram, 
as shown in Figure 3-1. 

So far we have been thinking of operations and communications 
as modeling the traditional procedure call/return mechanism. 
Communications can, however, represent more then just simple 
procedure calls. They may also model an Ada entry call and 
rendezvous. In this case, it may not be so obvious which 
way control should flow. Consider the example shown in Fig- 
ure 3-2(a), with the following object descriptions: 

DATA-ACCUMULATOR 

Provides : 

RUN 0 

Uses : 

SOURCE 

GET 

PACKET-TRANSMITTER 

SEND 

PACKET- TRANSMITTER 
Provides : 

RUN 0 

SEND (DATA-PACKET) 

Uses : 

DATA-LINE 

TRANSMIT 

The control flow of the RUN communication branches and flows 
into both of the objects in Figure 3-2(a). This means that 
there is a thread of control in both objects at the same 
time . That is, they run concurrently . In this example, 
the DATA ACCUMULATOR gathers real-time data from some ongoina 
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experiment into fixed size packets. These packets are then 
transmitted alonq a data line to a remote laboratory by 
PACKET TRANSMITTER. Fiqure 3-2 (a) shows that when the DATA 
ACCUMULATOR has accumulated enouqh data to form a packet, it 
initiates a communication with PACKET TRANSMITTER to hand 
over the packet to be transmitted. Note that in the case of 
concurrent objects, one object may have to wait before an 
operation it invokes is serviced. Section 3.3 will consider 
this further. An alternative desiqn is shown in Fiq- 
ure 3-2 (b). The new object descriptions are: 

DATA-ACCUMULATOR 
Provides : 

RUN 0 

get-packet 0 DATA-PACKET 

Uses : 

SOURCE 

GET 

PACKET-TRANSMITTER 
Provides : 

RUN 0 

Uses : 

DATA-ACCUMULATOR 

GET-PACKET 

DATA-LINE 

TRANSMIT 

Because control resides simultaneously in both objects, 
either object can initiate communications. In Fiq- 
ure 3-2 (b), when the PACKET TRANSMITTER is ready to transmit 
a new packet, it initiates a communication with the DATA 
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ACCUMULATOR. When the DATA ACCUMULATOR services this opera- 
tion, a DATA-PACKET is passed to the PACKET TRANSMITTER. In 
this example, both designs are equally aood. In more com- 
plicated concurrent systems, there are various reasons for 
choosing one direction of control flow over the other. In 
any case, to change the design in this way requires a change 
in the direction of an arrow on the object diagram and the 
modification of the appropriate object definitions. 


RUN 



(b) 

Figure 3-2. Concurrent Objects 
3.2 DECOMPOSITION OF OBJECTS 

At its top level, any complete system may be represented by 
a single object. For example. Figure 3-3 shows a diagram of 
the complete SCHEDULE ORGANIZER of the last section. The 
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An external 


box labeled "USER" is an "external entity." 
entity is an object which is not included in the system, but 
which communicates with the top level system object. In 
this case terminal input/output operations are "serviced" by 
the USER. Note that this is a design diagram and thus shows 
the physical communications and data flows, not the higher 
level meaning that the data might have. Thus a user at a 
terminal sends and receives "TEXT" through the terminal 
operations . 



Figure 3-3. Schedule Organizer External Entities Diagram 

A system level object may communicate with several external 
entities. A diagram such as Figure 3-3 showing these com- 
munications is an "external entities diagram." Communica- 
tions with external entities are usually initiated by the 
system. In tact, external entities are often much like 
passive data objects, all of whose operations have a one 
directional data flow. A direct access or indexed file 
might be an exception to this, with a read operation taking 
an index as an argument and producing a record as the re- 
sult. Another exception is that some external object must 
start the system. That is, initially control resides some- 
where outside the system, and it must flow into the system 
for execution to begin. In Figure 3-3, the User invokes the 
SCHEDULE ORGANIZER using the RUN operation. A final example 
of control flowing into a system would be an asynchronous 
interrupt. This could be modeled by the interrupting entity 
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invoking an operation in tne concurrently running system. 
Servicing the operation would then model servicing the in- 
terrupt . 

The object SCHEDULE ORGANIZER in Figure 3-3 represents a 
packaging of the complete object diagram of Figure 3-1. 
Working in the other direction. Figure 3-1 is a "decomposi- 
tion" of the object SCHEDULE ORGANIZER. This can be expanded 
into the idea of stepwise refinement for objects and object 
diagrams. Beginning at the system level, each object can be 
refined into a lower level object diagram. The result is a 
leveled set of object diagrams which completely describe the 
structure of a system down to the procedural level. 

For example. Figure 3-4 shows the decomposition of ADDRESS 
BOOK, which would be the beginning of the next level decom- 
position of Figure 3-1. The object descriptions for this 
diagram are: 

ADD 


Provides : 

ADD (NAME + ADDRESS) 

Uses : 

FIND-ADDRESS 

ADDRESSES 


CHANGE 

Provides: 

CHANGE . (NAME + ADDRESS) 

Uses : 

FIND-ADDRESS 

ADDRESSES 


LOOKUP 

Provides : 

LOOKUP (NAME) ADDRESS 
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FIND-ADDRESS 


Provides : 

FIND-ADDRESS (NAME) INDEX 

Uses : 

ADDRESSES 


ADDRESSES 

Contains : 

ADDRESS-LIST: {NAME + ADDRESS) 

All operations that lead "off the edges" of Figure 3-4 cor- 
respond to communications with the higher level ADDRESS BOOK 
object of Figure 3-1. This idea of "balance" is similar to 
that in leveled data flow diagramming. All operations pro- 
vided by an object must appear in its decomposition diagram, 
and all communications "to the outside world" on the lower 
level diagram must be reflected in communications with the 
higher level object. 

In Figure 3-4, the object ADDRESS BOOK has been completely 
decomposed into procedures. There is one procedure for each 
basic ADDRESS BOOK operation, and one additional procedure 
which is only used internally^ Besides the procedures in 
Figure 3-4, there is also the object ADDRESSES. As in pre- 
vious diagrams, an object such as this represents a store of 
data. Since it represents the internal state data of the 
higher level object, it is called a "state object." Proce- 
dures and states are really degenerate objects. Procedures 
are objects which have no internal state data and only serv- 
ice one operation. State objects contain data and only 
service operations to retrieve and update that data. All 
operations to a state object implicitly have one data flov; 
into or out of the object. Note that the object description 
of ADDRESSES above indicates the this state object contains 
a list of names and their associated addresses. 
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Thus, using procedure and state objects, we have exposed the 
guts of ADDRESS BOOK as a state machine in the sense of Fig- 
ure 2-4. At this low level we have defined exactly what 
state information and procedures are in ADDRESS BOOK. if 
necessary, it is now possible to further decompose the pro- 
cedures by more traditional means. As a rule, procedures 
should not contain full objects or states. If they do, they 
should be considered as full objects themselves, even if 
they perform only one operation. 

The main point of the above discussion is that any system 
can be represented as a single top-level object which can be 
successively decomposed, until at the lowest level we reach 
"degenerate objects." There are three types of degenerate 
objects. We have presented two types already: procedures 

and states. The third type is the "actor" object. Like a 
procedure, an actor has no state data . However, an actor 
does have state, in a sense, having to do with how it handles 
the flow of control. An actor object can control the serv- 
icing of its operations. This is primarily important in the 
commun lea t xon between concurrent objects. 

3.3 ACTOR OBJECTS 

When a procedure operation is invoked, the procedure services 
it immediately. If more than one object concurrently invokes 
the operation at the same time, then they are serviced con- 
currently. Thus, an object which is made up of just proce- 
dures and states has no control of the servicing of its 
operations. If several operations are invoked concurrently, 
they will be serviced concurrently, without any coordination 
between them. This can cause undefined simultaneous altera- 
tion to internal state data and other unpleasant results. 

The basic problem is that multiple flows of control enter 
the object and proceed through it independently of each other. 
This problem can be solved with the use of actor objects. 
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An actor object can dynamically decide when to service one 
of its operations. An object which invokes an actor opera- 
tion must wait first for the actor to decide to service the 
operation, and then for the servicing to be completed. Only 
one invocation of a specific operation is serviced at a time, 
in a first come, first serve order for each operation. If, 
while servicing one operation, an actor decides to service 
another, then the servicing of the first operation is effec- 
tively suspended until the servicing of the second one is 
finished. Thus, several control flows can enter an actor, 
but only one can be active at any one time. 

As a simple example, an actor object can be used to represent 
a version of the classical semaphore (see Figure 3-5) : 

SEMAPHORE 

Provides : 

WAIT 0 
SIGNAL 0 


SEMAPHORE 

L / 


READY 


Figure 3-5. Semaphore Actor 
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READY 


Contains : 

READY : BOOLEAN 

At any one time, the SEMAPHORE will service either the WAIT 
operation or the SIGNAL operation, but not both. It decides 
which operation to service by usinq a READY flaq. If the 
SEMAPHORE is not READY, then it will accept only SIGNAL op- 
erations, and any objects invokinq the WAIT operation will 
indeed have to wait. When the SEMAPHORE services a SIGNAL 
operation, it becomes READY. While the SEMAPHORE is READY, 
it will also service WAIT operations, of which there already 
may be some invocations pendinq. When it services a (sinqle) 
WAIT operation, the SEMAPHORE once aqain becomes not READY 
until the next SIGNAL operation. We assume that initially 
the SEMAPHORE is READY. Note that there is no way to decom- 
pose SEMAPHORE into procedures, because the availability of 
its operations chanqes over time . 

A semaphore can, for example, be used to ensure safe access 
to data common to concurrent objects. Fiqure 3-6 shows such 
a use. When either of the two procedures wants to access 
the common data, it invokes the SEMAPHORE WAIT operation. 
When this operation is serviced, the procedure can safely 
access or update the data, and all other accesses will be 
held up until the SEMAPHORE is SIGNALed. Alternatively, 
this same effect could be achieved by defininq a new actor 
object (see Fiqure 3-7): 

DATA- PROTECTOR 

Provides : 

READ 0 DATA 
WRITE (DATA) 
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The DATA PROTECTOR actor would only service one READ or WRITE 
operation at a time, thus protecting COMMON-DATA from simul- 
taneous access. Either Figure 3-6 or 3-7 could be the de- 
composition of a "PROTECTED COMMON DATA" object which would 
provide READ and WRITE operations like the DATA PROTECTOR. 
However, in the composite object both the lower level use of 
actors and the internal state would be hidden. 


3.4 TRANSLATING OBJECT DIAGRAMS INTO ADA 

Using the object diagram notation, we can build a set of 
diagrams which completely describe the design structure ot a 
system. Once this is done, the next step is to translate 
the design diagrams into code which provides a skeletal 
structure in which the remaining pieces of the system can be 
implemented. Though object diagrams provide a fairly gen- 
eral method for describing object-oriented designs, this 
translation step is most direct into Ada or similar lan- 
guages. The correspondence between our object notation and 
Ada is straightforward; 


Object Diagram 


Ada 


Object 

Procedure 

State 

Actor 

Communication 


Package 

Procedure/Function 
Package/Task Variables 
Entries/Accepts 
Procedure/Function/Entry Call 


To demonstrate the translation process, we return to the 
SCHEDULE ORGANIZER example. The first decomposition of this 
object was into three objects: USER INTERFACE, ADDRESS BOOK 

and DATE BOOK. We can now create package specifications for 
these objects based on the first level decomposition diagram 
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(Fiqure 3-1). Operations are defined in the packaae which 
services them. The resultinq specifications are: 

packaqe USER_INTERFACE is 
procedure RUN; 
end USER_INTERFACE; 
package ADDRESS BOOK is 


type ADDRESS 

is 

record 


STREET 

: STRING (1. .30) ; 

CITY 

: STRING (1. .20) ; 

STATE 

: STRING (1. .2) ; 

ZIP 

: STRING (1. . 5) ; 

end; 



procedure ADD 

(NAME: in STRING; 

ENTRY: in ADDRESS) ; 
procedure REMOVE 
(NAME: in STRING) ; 
procedure CHANGE 
(NAME: in STRING; 

ENTRY: in ADDRESS) ; 
function LOOKUP 
(NAME: in STRING) 
return ADDRESS; 

end ADDRESS BOOK; 

package DATE BOOK is 

type DATE is 
record 

YEAR : INTEGER range 00 .. 99; 

MONTH : INTEGER range 1 . . 12 ; 

DAY : INTEGER range 1 .. 31; 

end record; 

type TIME is INTEGER range 0 .. 23; 

procedure GET_APPOINTMENT 
(DAY; in DATE; 

HOUR: in TIME; 

NAME: out STRING; 

PLACE: out ADDRESS_BOOK .ADDRESS) ; 
procedure MAKE_APPOINTMENT 
(DAY: in DATE; 

HOUR: in TIME; 

NAME: in STRING) ; 
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procedure CANCEL_appointment 
(DAY: in DATE; 

HOUR: in TIME) ; 

end DATE BOOK; 

The main proqram would then have the form: 

procedure SCHEDULE ORGANIZER is 
-- qlobal type definitions 


-- packaqe specifications 

• 

packaqe body USER_INTERFACE is separate; 
package body ADDRESS_BOOK is separate; 
package body DATE_BOOK is separate; 

begin 

USER_INTERFACE. RUN; 
end SCHEDULE_ORGANIZER; 

The system RUN operation in Figure 3-3 represents the invo- 
cation of the SCHEDULE_ORGANIZER main procedure by the user. 
This in turn causes the call of USER_INTERFACE. RUN, passina 
the flow of control to the USER_INTERFACE. Note that pack- 
age USER_INTERFACF. has only the one RUN procedure. Since it 
has only this one operation and since it is active for the 
entire time the system is running, it would be acceptable to 
implement USER_INTERFACE as a procedure. The main proqram 
would then be just the call "USER_INTERFACE” . Note that 
this would not change the status of USER INTERFACE as an 
object on the object diagram (Figure 3-1) . At the next 
level, we could now code the declarative part of the bodies 
of the above three oackaaes. As an example, consider the 
ADDRESS_BOOK package. From the decomposition object diagram 
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tor object ADDRESS BOOK (Figure 3-4 ) , we can construct the 
following body; 

separate (SCHEDULE_ORGANIZER) 
package body ADDRESS_BOOK is 

-- type definitions ~ 

type ADDRESS_RECORD is 

record 

NAME ; STRING; 

ENTRY : ADDRESS ; 

end record; 

BOOK_SIZE : constant := 100; 

type ADDRESS LIST TYPE is 

array (1. .BOOK_SIZE) of ADDRESS_RECORD ; 

-- internal state 

ADDRESSES_LIST ; ADDRESS_LIST_TYPE ; 

• 

procedure ADD (NAME; in STRING; ENTRY; in ADDRESS) is 
separate; 

procedure REMOVE (NAME; in STRING) is separate; 
procedure CHANGE (NAME; in STRING; ENTRY; in ADDRESS) 

is separate; 

function LOOKUP (NAME; in STRING) return ADDRESS is 
separate; 

end ADDRESS_BOOK; 

To complete the system, we could implement the remaining pro- 
cedures using more traditional functional desian methods. 

The only applicable Ada unit not used in the above example 
is the task. In Ada, for the flow of control to actually 
reside in two units at the same time, these units must be 
tasks. Therefore, if there are concurrent objects in an 
object diagram, then at least some part of them must be 
translated into tasks. Actually, higher level concurrent 
objects which are decomposed into other objects generally 
can still be translated as just packages. At the lowest 
level, however, at least some of the degenerate objects com- 
posing the higher level object must be tasks. The degenerate 
object that usually signals the use of an Ada task is the 
actor . 
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An actor represents quite closely the rendezvous mechanism 
of an Ada task body. An Ada task can, however, have 
internal state data, while an actor cannot. Thus an actor 
would translate into a task without a declarative part, and 
any state data would be contained in a surrounding package. 

It is common to combine the surrounding package with the 
task to create a composite Ada object which represents the 
actor and the data that it alone uses. For example, the 
SEMAPHORE actor of Figure 3-5 could be translated into: 

task SEMAPHORE is 
entry SIGNAL; 
entry WAIT; 
end SEMAPHORE; 

task body SEMAPHORE is 

READY : BOOLEAN := TRUE; state object READY 

begin 

loop -- begin actor SEMAPHORE 

select 

when READY => 
accept WAIT; 

READY := FALSE; 

or 

accept SIGNAL; 

READY := TRUE; 
else 

terminate; 
end select; 

end loop; -- end of actor 

end SEMAPHORE; 

Note how the READY flag is included in the task, and how the 
actor object represents the executable part of the task body. 
A rendezvous with the task corresponds to a communication 
with the actor object and accepting an entry corresponds to 
servicing an operation. 

Now, if we used SEMAPHORE to implement a PROTECTED COMMON 
DATA object with the decomposition shown in Figure 3-6, we 
could translate the object as a package even though it would 
be concurrent with other objects. It v\70uld, however, contain 
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the SEMAPHORE task as the translation of part of its decom- 
position. The higher level package translation might be: 

package PROTECTED_COMMON_DATA is 
procedure READ(X: out DATA); 
procedure WRITE(X: in DATA); 
end PROTECTED_COMMON_DATA ; 

package body PR0TECTED_C0MM0 N_data is 

COMMON_DATA ; DATA; -- internal state 

task SEMAPHORE is 
entry SIGNAL; 
entry WAIT; 
end SEMAPHORE; 

task body SEMAPHORE is separate; 

procedure READ(X: out DATA) is 
begin 

SEMAPHORE.WAIT; 

X := COMMON_DATA; 

S EMAPHORE . SIGNAL ; 
end READ ; 

procedure WRITE (X: in DATA) is 
begin 

SEMAPHORE.WAIT; 

COMMON_DATA := X; 

S EMAPHORE . SIGNAL ; 
end WRITE; 

end PROTECTED COMMON DATA; 
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The aesign of Figure 3-7 would actually be a better use ot 
Ada tasking. In this case, PROTECTED COMMON DATA could be 
translated into a single task; 

task PROTECTED_COMMON_DATA is 
entry read (X; out data) ; 
entry WRITE (X; in DATA) ; 
end PR0TECTED_C0MM0N_DATA; 

task body PROTECTED_COMMON_data is 

COMMON_DATA ; DATA; -- internal state 

begin 

loop -- begin actor DATA- PROTECTOR 

select 

accept READ (X: out DATA) do 
X ;= COMMON_DATA; 
end READ; 
or 

accept WRITE (X; in DATA) do 
COMMON_DATA ;= X; 
end WRITE; 
or 

terminate; 
end select; 

end loop; -- ena of actor 

end PROTECTED COMMON DATA; 
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SECTION 4 - OBJECT-ORIENTED DESIGN 


Using the concepts and notation of object diagrams, this 
section deals with two main questions: 

• What makes a good object? 

• How are designs constructed from objects? 

While we cannot provide all-encompassing answers to these 
questions, we do provide principles to guide the design 
process. They are heuristics, not laws, but they do provide 
a powerful means for constructing and comparing alternative 
designs. They are thus tools to aid the software designer 
in his (or her) engineering art. 

4.1 PRINCIPLES FOR DESIGNING OBJECTS 

The intent of an object is to represent a problem-domain 
entity. The concept of "abstraction" deals with how an 
object presents this representation to other objects 
[Dijkstra 68, Liskov 74, Ledgard 77, Booch 83]. As software 
models, objects should also act as black boxes to allow easy 
debugging and maintenance. The concept of "information hid- 
ing" deals with what an object keeps secret from other ob- 
jects [Parnas 72] . These two concepts provide the main 
guides for assessing an object. A "good" object thus repre- 
sents a problem domain entity and hides closely-related in- 
formation that is likely to change if the implementation of 
the object changes. 

There is a spectrum of abstraction, from objects which 
closely model problem domain entities to objects which 
really have no reason for existence. The following are some 
points on that scale: 

Entity Abstraction Best 

Action Abstraction 

Virtual Machine Abstraction 

▼ 

Coincidental "Abstraction" Worst 
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Each kind of abstraction in this scale is a subset of the 
kind below it. 

An "entiJty abstraction" is an object which represents a use- 
ful model of a problem domain entity. The entity could be 
as concrete as a hardware sensing device or more abstract, 
such as a compiler symbol table. We include "data abstrac- 
tion" under entity abstraction as denoting objects which 
define type managers. 

"Action abstraction" moves from abstracting the properties 
of t hings to abstracting the properties of actions . An ac- 
tion abstraction is an object which provides a generalized 
set of operations which all perform the same kind of action. 
A general "input handler" or a "math processor" would be 
action abstractions. Procedures are generally action ab- 
stractions. 

"Virtual machine abstractions" are objects which group 
together operations which are all used by some superior 
level of control or all use some junior level set of opera- 
tions. While the concept of a "virtual machine" will be 
useful later on, it is not a very good criterion for con- 
structing objects. Such objects group together unrelated 
actions on the basis of their being at about the same "level 
of control." 

Finally, "coincidental abstraction" is really no abstraction 
at all. A coincidentally abstract object packages a set of 
operations which have no relation to each other in any 
substantial way and probably do not even get along well 
together . 

Information hiding is complementary to abstraction. The 
stronger the abstraction of an object, the more details are 
suppressed by the abstract concept. The principle of infor- 
mation hiding states that such details should be kept secret 
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from other objects [Parnas 72, Booch 83]. While good ab- 
straction promotes information hiding, and often vice versa, 
it is possible to construct objects which have high abstrac- 
tion, but provide ways to expose their contents. Conversely, 
it is possible to hide information well without constructing 
good abstractions. The best objects should thus be con- 
structed to provide operations on abstract entities and to 
carefully hide internal representations and related secrets. 

4.2 PRINCIPLES FOR DESIGNING SYSTEMS 

Following [Rajlich 85] , we will consider two basic orthogonal 
hierarcfiies in software system designs. The "parent-child 
hierarchy" deals with the decomposition of larger objects 
into smaller component objects (as discussed in Section 3.2). 
The "seniority hierarchy" deals with the organization of a 
set of objects into "layers." Each layer defines a "virtual 
machine" [Dijkstra 68] which provides a set of services to 
senior layers. 

The object diagram notation can distinctly represent these ' 
hierarchies. The leveling of object diagrams directly ex- 
presses the parent-child hierarchy (see Figure 4-1) . On the 
other hand, the topology of connections on a single object 
diagram shows the seniority hierarchy (see Figure 4-2). 

(Note the quite literal orthogonality of these two hier- 
archies in Figure 4-li) Any layer in a seniority hierarchy 
can call on any operations in junior layers, but never any 
operation in a senior layer. Thus, if we group objects into 
virtual machine layers, these layers are always related by a 
directed , acyclic graph . From Figure 4-2 we would get the 
graph shown in Figure 4-3. All cyclic relationships between 
objects must be contained within a virtual machine layer. 
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Figure 4-1. Parent-Child Hierarchy 
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Figure 4-2. Seniority Hierarchy 
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VIRTUAL MACHINE LAYER 1 


VIRTUAL MACHINE LAYER 2 


Figure 4-3. Virtual Machine Graph 









The general structure of an object-oriented design as pre- 
sented here is a seniority hierarchy of virtual machines, 
each of whose components is decomposed into children objects. 
The children of each object are themselves organized in sen- 
iority hierarchies, and so on. Figure 4-4 shows a stylized 
overview of the top level object diagram of such a system. 
Figure 4-4 uses the words "afferent” and "efferent" in the 
input/output sense of [Yourdon 79] . Thus the virtual ma- 
chines provide operations for THE SYSTEM to input, process 
and output data. Lower level object diagrams will also have 
a structure similar to Figure 4-4. However, instead of a 
single most-senior object, they will generally have a set of 
senior level objects which implement the operations of the 
parent object. These senior objects use the junior virtual 
machine operations to do this. 

Note that we have not made the virtual machine layers in 
Figure 4-4 into objects themselves. Such objects would gen- 
erally have only (surprise!) virtual machine abstraction. 

Each virtual machine layer should therefore be composed of 
objects with higher abstraction. Figure 4-5 shows one ap- 
proach, reminiscent of structured design [Yourdon 79] . These 
virtual machine components would have, at best, action ab- 
straction. A better approach is to identify appropriate 
problem domain entities and create entity abstractions which 
package afferent, transform and efferent operations for each 
entity (see Figure 4-6) . The parent-child decomposition of 
the most-senior object THE SYSTEM might still be a struc- 
tured design style afferent-transform-efferent hierarchy. 

But now it could be designed as if the virtual machine oper- 
ations where "primitive operations" in an extended language. 
These "junior level" (in a control sense) operations are 
themselves defined within objects which represent the spe- 
cific entities with which the operations deal. 
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Figure 4-5. Input/Process/Output Virtual Machine 








Figure 4-6. 


A Better Virtual Machine Decomposition 






I 


The seniority hierarchy deals mainly with control; tne 
senior levels control the operation of the junior levels. 

To varying degrees, senior levels can also control the data 
flow and interaction between components of junior layers. 
Consider the automated manufacturing plant simulation system 
diagrammed in Figure 4-7. Note that the junior components 
do not interact directly. As part of its use of the virtual 
machine operations, the PLANT SIMULATOR must control the 
flow of data between the three virtual machine components. 
This has the advantage that none of the junior components 
needs to know anything about any of the other components. 
However, the senior object has to do a lot of work simply 
passing data from one junior object to another. 



Figure 4-7. An Automated Manufacturing Plant Simulation 
System 

Suppose we reniove the data flow control from the senior 
object and let the junior objects pass data directly (see 
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Figure 4-8) . This type of design was, in fact, used for 
part of our pilot project simulator. The senior object has 
been reduced to simply activating various operations in the 
virtual machine. These operations can then use other 
operations internal to the virtual machine to pass data and 
commands between component objects. This means that some 
objects must have knowledge of some other objects within the 
virtual machine layer, limiting any possible future uses of 
the components apart from this virtual machine. An added 
complication is the possible need for buffering of incoming 
data as state information in some objects, until the next 
control activation from the senior object. 



Figure 4-8. Plant Simulator With Junior-Level Connections 

We can even remove the senior object completely by distrib- 
uting control among the junior objects. By making the 

4-11 


0252 






remaininq objects concurrent and passinq data throuqh syn- 
chronizinq rendezvous, we can also often eliminate the above 
need for bufferinq. Fiqure 4-9 shows an example of such a 
desiqn. The seniority hierarchy has collapsed, leavinq a 
"homoloqous" or non-hierarchical desiqn [Yourdon 79] (non- 
seniority -hierarchical, that is; the parent-child hierarchy 
still remains) . A desiqn which is homoloqous at all parent- 
child levels is very similar to what would be produced by 
Georqe Cherry's PAMELA^ methodoloqy for real-time applica- 
tions [Cherry 85a, Cherry 85b]. 


RUN 



Fiqure 4-9. Plant Simulator, Homoloqous Desiqn 

It is sometimes possible to recover a seniority hierarchy 
from a seeminqly homoloqous desiqn. Fiqure 4-10 shows a 
simplified real-time aircraft on-board monitorinq system. 

The system is hiqhly concurrent without centralized control. 
Note the representation of interrupts ("SMOKE ALARM" and 
"KEYSTROKE") as operations oriqinatinq outside the system. 
Due to the real-time nature of the system, actions of the 
system are caused by outside events, with control flowinq, 

IpAMELA is a trademark of Georqe W. Cherry. 
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rouqhly, from the left in Figure 4-10 to the right, where 
results are displayed for the pilot. Thus, by turning Fig- 
ure 4-10 on its side, the objects become organized in a 
seniority hierarchy (see Fiaure 4-11) . The diagram has been 
reorganized according to calling directions. Since action 
is initiated by external stimulus, the input interfaces are 
at the top of the seniority hierarchy as two concurrent, 
most senior objects. The system is input driven in a very 
literal sense: the senior-level, controlling objects are 

the ones closest to the input. The junior-level, controlled 
objects produce the output. This is a quite natural organi- 
zation for such an embedded, real-time system. 
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Figure 4-10. Aircraft Monitoring System 
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Figure 4-11. Aircraft Monitoring System With Seniority 
Hierarchy 

The main advantage of a seniority hierarchical design is 
that it reduces the "coupling" (in the sense of [Yourdon 79] ) 
of the virtual machine components. This is because each 
virtual machine layer needs to know nothing about its sen- 
iors. It is possible to completely replace senior-level 
controllers without affecting the junior levels at all. In 
the stronger version where the senior levels also control 
data flow, the virtual machine component objects are even 
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decoupled from each other. Tdis means that they are parti- 
cularly adaptable to future use, and that they are less 
likely to propagate or be affected by changes in the system. 


The centralization of the procedural and data flow control 
can make the system easier to understand and modify. On the 
other hand, this very centralization can cause a messy 
bottleneck in the data flow between objects. Even if this 
is eliminated, complicated scheduling can sometimes result 
in a similar control bottleneck. In addition, if the con- 
trol and scheduling of junior objects depends heavily on 
information internal to them, then centalizing control could 
reduce their level of information hiding and abstraction. 

In this case a more homologous design would be appropriate. 
In large real-time systems with low level external stimuli, 
it can be particularly useful to eliminate the senior level 
data and control bottleneck and take advantage of distrib- 
uted, concurrent control [Cherry 85a] . Even in this case it 
is sometimes possible, as discussed above, to recast a con- 
current, homologous design in the form of a seniority hier- 
archy without the usual disadvantages. In general, however, 
the best design will be between the extremes of use of the 
seniority hierarchy. 
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SECTION 5 - ABSTRACTION ANALYSIS 


Object diagrams and the object-oriented design concepts dis- 
cussed in the previous sections can be used as part of an 
object-oriented life cycle. Section 3.4 described how ob- 
ject diagrams can be translated into Ada. However, we must 
also be able to create an initial object-oriented design 
from a system specification. We use structured analysis to 
develop the specification [DeMarco 79] . The data flow dia- 
grams of a structured specification provide a leveled, 
graphical notation containing the information needed to rep- 
resent abstract entities, but in a form emphasizing data 
flow and data transformation. "Abstraction analysis" is the 
process of making the transition from a structured specifi- 
cation to to an object-oriented design [Stark 86]. 

The main idea in producing an initial design is to identify 
objects, map them back to the requirements, and then identify 
the operations. Abstraction analysis transforms a structured 
specification into an object-oriented design by first iden- 
tifying abstract entities and a tentative control hierarchy, 
and then identifying objects, operations, and a hierarchy of 
virtual machines. As an intermediate step between data flow 
diagrams and the control-flow oriented object diagrams we 
create an "entity graph". This graph shows the interconnec- 
tions of the abstract entities in the problem domain from a 
control point of view, where the data flow diagrams give a 
data exchange point of view. Since the direction of control 
and design complexity are also considered in creating an 
object diagram, the best objects and the best abstract enti- 
ties are not necessarily the same. 

Operations are identified from processes and data stores con- 
tained by an object, and by the data flow between objects. 
Fortunately, data flow diagrams are analogous to object dia- 
grams in that they are developed from a higher level of 
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abstraction to a more detailed view. Our approach can qen- 
erate leveled object diagrams because of this property. We 
will first aiscuss the ideas used in performing abstraction 
analysis and how they are used to identify objects, we will 
then discuss the entire process of designing from a struc- 
tured specification. 

Section 4 discussed the tradeoff between the loose coupling 
generated by a strong seniority hierarchy and the real time 
performance of a homologous design. Here we will describe 
the nature of abstraction and control issues that have to be 
facea. The procedure used to produce an obgect diagram first 
entails identifying central entities and virtual interfaces, 
secondly identifying objects, and then using the results of 
these two steps to produce an object diagram. 

We will illustrate this process with a version of the Gamma 
Ray Observatory (GRO) Attitude Dynamics Simulator (GRODY) 
pilot project [Agresti 86J. Analysts use an attitude dy- 
namics simulator to verify the correctness of a spacecraft's 
attitude control laws. Such a system must simulate the 
spacecraft control system, model the spacecraft's response 
to control and provide simulated input to the control system. 
Figures 5-1 and 5-2 are the two highest level data flow dia- 
grams used in this example. 

5. 1 IDENTIFYING CENTRAL ENTITIES AND VIRTUAL INTERFACES 

A "central entity" in abstraction analysis is nearly iaenti- 
cal to a central transform in structured design. In struc- 
tured design [Yourdon 79] input and output data flows are 
examined and followed inwards until they reach the highest 
level of abstraction. The processes between the inputs and 
the outputs form the central transform. In abstraction 
analysis a designer does the same, but also examines the 
central transform to determine which processes and states 
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GRODY LEVEL 0 SATA FLOW mm 
















represent the best abstract model of what the system does. 

For example, it is clear from Fiqure 5-1 that SIMULATE GRO 
SPACECRAFT is the central transform for GRODY. Examininq 
Fiqure 5-2 we can arque that SIMULATE SPACECRAFT CONTROL is 
the central entity, as the purpose of a dynamics simulator 
is to test the control laws. We could continue to desiqn 
usinq either assumption. We choose to make SIMULATE 
SPACECRAFT CONTROL the central entity. 

After identifyinq the central entity we identify what ab- 
stract entities are supportinq it. The idea is to follow 
the afferent and efferent data flows away from the central 
entity and to qroup related processes and states alonq these 
data flows, forminq abstract entities. 

In creatinq the level 0 object diaqram for GRODY we will 
build a recast data flow diaqram step by step as we identify 
abstract entities. Fiqure 5-3 shows the process SIMULATE 
SPACECRAFT CONTROL and the adjacent processes and data flows. 
We look at the data flows in and out of the central entity 
and identify entities suoportinq these data flows. This is 
done by qroupinq these processes and states into entities 
with hiqh abstraction. With GRODY, each process and state 
in Fiqure 5-3 maps to an entity. This is due to the speci- 
fication beinq hiqhly abstract at the top level, rather than 
to any rule mappinq data flow diaqram processes directly 
into entities. Later examples show how related processes 
are qrouped into a sinqle entity. Groupinq related proc- 
esses may require examininq lower level data flow diaqrams, 
althouqh in this case it does not. 

To ensure that we start with a stronq seniority hierarchy we 
use the concept of virtual machine layers discussed in Sec- 
tion 4.2. We start by assuminq the existence of a "most- 
senior" object that calls on a virtual machine consistinq of 
the central entity and the entities that directly support 
the central entity. Fiqure 5-4 is an entity qraph for 
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GRODY that contains only the hiqhest virtual machine level. 
Squares represent entities, with the identifyinq numbers of 
processes or states from the data flow diaqram written in 
the squares to show the mapping between requirements and 
entities. Arrows show the flow of control between GRODY and 
! the virtual machine entities, and lines with no indication 

I 

j of direction represent potential communications between 

i entities. 

I 



Figure 5-3. Support of Central Entity 



Figure 5-4. First Level of Entities 
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At this point the only control flow we want to see is the 
"most senior" object controlling the first group of entities 
identified. We add other control flows later, first in 
response to system requirements not captured on data flow 
diagrams, and secondly to optimize our virtual machine hier- 
archy. We have not made any determination about how data 
are passed between the entities. The options are to pass 
data directly between entities or to pass it through the 
most-senior entity. 

The next group of entities is again identified by examining 
data flows, processes and states; this time the ones that 
are one step further removed from the central entity. For 
example. Figure 5-2 shows that the processes MODEL SENSORS 
and MODEL ACTUATORS are both supported by 1.1 MODEL DYNAMICS 
St ENVIRONMENT and the data store DO 2 SIMULATION PARAMETER 
STORE, and by D03 SIMULATION DATASTORE. MODEL SENSORS is 
also supported by the external entity STAR CATALOG. Simi- 
larly, Figure 5-l_shows that UPDATE GROUND DATABASE is sup- 
ported by the user, and that the SIMULATION DATASTORE is 
supported by PREPARE SIMULATION RESULTS which is supported 
by the user. We then draw a data flow diagram (Figure 5-5) 
reflecting these relationships. To make identifying objects 
easier, we leave the names of processes and data stores on 
the diagram, but use shorthand labels for data flows when 
needed. In Figure 5-5 we have used shorthand labels in 
areas where the interactions are more complex. 

Identifying entities is almost as straightf oward for this 
part of GRODY as it was for the first set of entities. The 
user is already an external entity. PREPARE SIMULATION 
RESULTS and MODEL DYNAMICS & ENVIRONMENT also map directly 
into entities. By examining the data flows coming from the 
datastore SIMULATION PARAMETER STORE we can determine that 
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Dataflow labels 

A: Sensor Reference Data • Attitude • Angular velocity 

B: Center of Hass • Geoeagnetlc Field in BCS 

C: Vheel Angular nonenta • Array & Antenna Angles 

0; Sensor Comnands 

E: Hardeare Status 

F; Actuator Connands 

6: Vheel Speeds « Torquer Oipole 

H: Ground Oatadase Options 

I: Ground Oatadase Report 

J; Results Processing Options 

K: siAulation Results 


Figure 5-5. DFD With Added Processes 
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this data store can be separated into parts supportinq proc- 
esses 1.1, 1.2, and 1.3. Thus the initial conditions for 
these three processes are associated with the appropriate 
entity, rather than having a separate entity acting as a 
global data area. Figure 5-6 shows the entity graph with 
the newly identified entities added. 



Fiaure 5-6. Next Level of Entities 

This process continues until the ends of the afferent and 
efferent data flows are reached. Figure 5-7 is a recast 
data flow diagram for GRODY. This diagram is a releveling 
of the original data flow diagrams to reflect support of the 
central entity. As before, we have used the shorthand 
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labels for the data flows, 
in identifying objects. 


This diagram will later be used 



Dataflow Labels 

A: Sensor Reference Data • Attitude • Angular Velocity 

6: Center of nass « Geonagnetlc Field in 8CS 

C: Vheel Angular Honenta • Array & Antenna Angles 

0: Sensor ConiRands 

E: Hardware Status 

F: Actuator Conaanos 

G; Vheel Speeds ♦ Torquer Dipole 

H: Ground Database Options 

I : Ground Database Report 

J: Paraneter Database Options 

K: Paraneter Database Report 

L: Results Processing Options 

fi: Sinulation Results 

Figure 5-7. Recast GRODY Data Flow Diagram 
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Figure 5-8 is an initial entity graph for GRODY. In Fig- 
ure 5-8 we show the RUN operation flowing from the user to 
the most senior entity GRODY. This signal would come from 
outside the entity graph if GRODY were started by the opera- 
tor or by the system when it is powered up. The RUN signal 
and the control flowing from GRODY are the only edges on the 
entity graph that now have direction. Assignment of direc- 
tion to the other edges is discussed in the next subsection. 



Figure 5-8. GRODY Entity Graph 
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What we have shown so far is for illustration. An actual 
design would be derived in fewer steps. A complete recast 
data flow diagram could be drawn after the central entity is 
identified, and then the initial entity graph can be drawn 
using the "inside out" method described above. In the ex- 
ample shown this far, the initial entity graph will be ex- 
tensively modified before the final objects are found. When 
a recast data flow diagram is drawn before identifying enti- 
ties the relationships between processes and states are 
easier to see. This should make the entities identified 
closely related to the final objects. In some cases it is 
possible to identify objects directly from a recast data 
flow diagram. 

5. 2 IDENTIFYING OBJECTS 

The first step in identifying objects from an entity graph 
is to add directions of control where the problem determines 
the control flow. Figure 5-9 is the GRODY entity graph with 
these modifications. The database entities and external 
entities are "passive," so they all have control flowing 
into them. The idea of the USER being "controlled" runs 
against the intuitive idea of a user controlling software, 
but in the sense of control flow what happens is that a 
software system will call an operation such as TEXT 10. GET 
to f ind out what the user wants to do. 

SIMULATE SPACECRAFT CONTROL is required to give simulated 
control commands. This implies that MODEL SENSORS and MODEL 
ACTUATORS are junior to SIMULATE SPACECRAFT CONTROL. UPDATE 
PARAMETER DATABASE is made senior to 1.1, 1.2, and 1.3 so 
that the user can control the state of these entities. We 
have not added the corresponding control flow between UPDATE 
GROUND DATABASE and 1.4 SPACECRAFT CONTROL because we have 
not determined whether ground commands will be requested by 
1.4 or whether they will be provided from outside. No 
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I direction of control is identified between MODEL SENSORS, 

MODEL ACTUATORS, and MODEL DYNAMICS & ENVIRONMENT. Nothing 
in the problem domain determines direction of control among 
these three entities. We will be able to choose these di- 
rections of control later based on virtual machine hierarchy 
considerations . 

1 

I 



Figure 5-9. Entity Graph With Control Flows 

The next step is to identify objects and to place them in a 
strong seniority hierarchy. We want to balance the level of 
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abstraction of each object, the desire for a qood seniority 
hierarchy, and the complexity of relationships between ob- 
jects. 

In our GPODY example, we can see from Figure 5-9 that 2.0, 

3.0, and 4.0 are all senior to the user, and that USER, 

GRODY, and 3.0 form a cyclic graph. This means that these 
five entities are all on the same virtual machine level. 
Entities 2.0, 3.0, and 4.0 all control databases, with the 
first two having sole control of the PARAMETER DATABASE and 
GROUND DATABASE, respectively. Since they all interact with 
the user, we create a USER INTERFACE by combining 2.0, 3.0, 

4.0, DOl, and D04. Combining the user and database interac- 
tions into a single object provides good entity abstraction. 
We will see later that D03 is not contained in USER INTERFACE 
due to virtual machine hierarchy considerations. The proc- 
esses and datastores in USER INTERFACE are circled on the 
recast data flow diagram (see Figure 5-10) . 

We chose the process 1.4 SIMULATE SPACECRAFT CONTROL as the 
central entity because it contains the control laws being 
tested by the simulator. This same consideration dictates 
the use of a separate SPACECRAFT CONTROL object. Process 
bubble 1.4 on the recast data flow diagram is circled to 
reflect this decision (see Figure 5-10 again) . We still 
have not chosen whether USER INTERFACE or SPACECRAFT CONTROL 
will be a senior object, nor do we want to until all the 
objects are identified. 

Entities 1.1, 1.2 and 1.3 pose a slightly more difficult 
problem. One alternative is to combine 1.2 MODEL SENSORS 
and 1.3 MODEL ACTUATORS into an ATTITUDE HARDWARE object. 

We can then make 1.1 a junior object so that 1.4 controls 
ATTITUDE HARDWARE which in turn controls 1.1 MODEL DYNAMICS 
& ENVIRONMENT. This hierarchy is one way of producing layers 
of virtual machines. Another alternative is to combine 1.1, 
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1.2 and 1.3 into a single object. We will call this object 
TRUTH MODEL because it provides "true” responses to control 
commands. In this case deciding the flow of control between 
entities 1.1/ 1.2 and 1.3 is defered until the child object 
diagram for TRUTH MODEL is generated. The first alternative 
yields objects with higher abstraction, but the second will 
give a simpler design. The TRUTH MODEL object has abstrac- 
tion somewhere between entity (model true spacecraft re- 
sponse) and action (model the related actions of sensors, 
actuators, dynamics and environment) abstraction. Thus we 
choose tne second alternative as "abstract enough" and as 
part of a good virtual machine hierarchy. Again, the proc- 
esses and datastores contained by the object are circled on 
the recast data flow diagram (Figure 5-10) . 



Figure 5-10. Recast GRODY DFD with Object Boundaries Shown 
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The data store D03 SIMULATION DATASTORE has not yet been 
associated with an object. It could be placed within the 
USER INTERFACE, but that would result in USER INTERFACE both 
calling TRUTH MODEL to initialize simulation parameters and 
being called by TRUTH MODEL to store results data. This is 
not necessarily bad, but we would like to avoid this situa- 
tion if it is possible to do so. To preserve our virtual 
machine hierarchy we define a SIMULATION RESULTS DATABASE 
that is junior to everybody. We have lost some of the ab- 
straction by splitting this object from USER INTERFACE, but 
both objects are still good abstractions, and we have gained 
a better control hierarchy. Figure 5-10 is now completed by 
circling the D03 SIMULATION DATASTORE. 

Figure 5-11 is the object diagram resulting from the' above 
analysis. We have chosen to make the USER INTERFACE senior 
to SPACECRAFT CONTROL, but the arrow between these two ob- 
jects could be reversed and we would still have a virtual 
machine hierarchy. The decision to make USER INTERFACE the 
senior object was based on the need to have the user control 
a simulation. The USER INTERFACE object "controls" the user 
by calling a read operation to get data or user options, and 
then calls on the other simulator components to perform the 
operation requested. The important concept here is that the 
decision was not made on the basis of the design rules dis- 
cussed above, but rather on what would be a more desirable 
way to meet the specification. 

Figure 5-11 shows a clear seniority hierarchy, but decisions 
still need to be made about how strong this hierarchy will 
be. Any changes can be made to Figure 5-11 that leave paths 
available for data to flow from a source to its correct des- 
tination. We can eliminate the communications among USER 
INTERFACE, SIMULATE SPACECRAFT CONTROL and TRUTH MODEL to 
get the design shown in Figure 5-12, which is loosely coupled 
and highly structured at its senior level. Alternatively, 



















we can combine GRODY and USER INTERFACE to give a design 
with more decentralized control, as in Figure 5-13. A third 
choice is to keep GRODY as an entity that performs scheduling 
but that does not exchange data with junior virtual machine 
levels. Then Figure 5-11 would stand as the final object 
diagram. We choose the decentralized configuration of Fig- 
ure 5-13 because we want to eliminate the bottlenecks that 
can be caused by a complex central control entity. The sen- 
iority hierarchy is still strong, but all data "fly non-stop" 
from their source to the destination. 



Figure 5-13. Less Centralized GRODY Design 
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The entities on the initial object diagram are now either 
objects or external entities, and we have fully considered 
flow of control issues. Before we can go on ana identify 
operations and complete the object diagram we must consider 
objects that are required but not visible from the analysis 
of a data flow diagram. For GRODY the only major require- 
ment we have not handled is scheduling and keeping track of 
simulated time. Two alternatives are to design from Fig- 
ure 5-13 and to have the "most senior" object GRODY handle 
the scheduling and the timing; or to create a timer object 
junior to SPACECRAFT CONTROL which will update the simulated, 
time. In the second case the scheduling is implicit in the 
response of junior objects to requests and commands from 
SPACECRAFT CONTROL. Figure 5-14 is the object diagram gen- 
erated by using this option. We choose the second option as 
a more decentralized design. 

5.3 DESIGN USING ABSTRACTION ANALYSIS 

Considering required objects completes the process of object 
identification. The next step is to formally map the speci- 
fications to objects and then to identify operations. 
Experienced designers can actually shorten the object iden- 
tification process from what is shown above by skipping the 
explicit use of entity graphs. The steps that are then 
taken are as follows; 

1. Identify central entity. 

2. Draw a recast data flow diagram. 

3. Identify objects and draw boundaries on recast DFD. 

4. Draw an object diagram with a hierarchy that best 
balances requirements for loosely coupled objects 
and for the elimination of data and control bottle- 
necks . 
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Figure 5-14. GRODY Object Diagram 

If entity graphs are used they are drawn as an intermediate 
stage between steps 2 and 3. 

After drawing the object diagram the design process consists 
of the following: 

1. Generate an object contents table. 

2. Identify operations. 

3. Label concurrent objects by adding simultaneous 

control . 

4. Generate data flow diagram for each object on the 
object diagram. 
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To make this a recursive process, the part of the recast 
data flow diagram describing each object is used, along with 
the associated lower level data flow diagrams, as a starting 
point for the identification of child objects. The object's 
operations provide central entities which the designer uses 
as a starting point for drawing an entity graph for the ob- 
ject. This graph is then used to identify child objects, 
and then the four steps above are taken to complete a child 
object diagram. Later we will construct the child object 
diagram for the TRUTH MODEL object on the GRODY level 0 ob- 
ject diagram (Figure 5-14, object 3.0). The steps listed 
above are described in more detail in the following subsec- 
t ions . 

5.3.1 GENERATING OBJECT CONTENTS TABLES 

The object contents table lists the objects on a diagram, 
the processes that each object will implement, the states 
hidden by each object on the diagram, and system considera- 
tions that are not captured by the data flow diagrams. 

Figure 5-15 shows the object contents table for the GRODY 
level 0 object diagram. The processes are listed to the 
level of detail needed to show the boundaries between ob- 
jects. The states and system considerations are also shown 
at an appropriate level. In Figure 5-14 the TRUTH MODEL 
object contains processes 1.1, 1.2, and 1.3 and SIMULATE 
SPACECRAFT CONTROL contains 1.4. Thus we have to break up 
process 1.0 when we write the object contents table. In 
Figure 5-15 the states hidden are all data stores, but they 
can also be data elements or data records that are a subset 
of a data store. It is necessary to show a hidden state on 
the object contents table only when it is visible on a data 
flow diagram showing the interior of an object. For example, 
the object SPACECRAFT CONTROL certainly has internal state, 
but this state is not visible at this level. 
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user interface 

2.0 Update Paraneter Database 

3.0 Update Ground Database 

4.0 Prepare Simulation Results 
St;at9?: 

001 Parameter Database 
004 Ground Database 
spacecraft Control 
Prft£a.S,?^lL 

1.4 Spacecraft Control 
svatew Considerations 

required as object to test control lavs 
Truth Hod^ 

Processes 

1.1 hodel Dynamics a Environment 

1.2 nodel Sensors 

1.3 hodel Actuators 

D02 Simulation Parameter Store 

siauiaupii Results Database 

state 

003 Simulation Datastore 

Timer 

S ystem Considerations 

Simulator Is required to keep a simulated time 


Figure 5-15. Object Contents Table for GRODY 


5.3.2 USING THE RECAST DATA FLOW DIAGRAM WITH OBJECT 
BOUNDARIES 

Figure 5-10 shows the diagram for GRODY with the object 
boundaries drawn on top. In most cases object boundaries 
can be drawn around processes and data stores on the recast 
data flow diagram. If this is not possible, the child data 
flow diagrams or the data dictionary must be examined, and 
the parent process or data store must be divided among the 
appropriate objects. This kind ot adjustment will be demon- 
strated in more detail as we break down the TRUTH MODEL. 

5.3.3 IDENTIFYING OPERATIONS 

Identifying operations is a continuation of the direction- 
of-control analysis done for the entity graph. We use the 
direction of control that has been established, the data 
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flows across object boundaries, and the processes and states 
(data stores) connected by these data flows. Child data 
flow diaqrams and data dictionary entries are used to qain 
more details on the processes and data involved. 

For example, Fiqure 5-10 shows the data exchanqed between 
SPACECRAFT CONTROL and TRUTH MODEL. These data are qene rated 
by operations modelinq sensor and actuator behavior. These 
operations are provided by TRUTH MODEL and used by SPACECRAFT 
CONTROL. Fiqure 5-10 shows that 1.2 MODEL SENSORS and 1.4 
SIMULATE SPACECRAFT CONTROL communicate usinq the data flows 
"Sensor Data" and "Sensor Commands". Examininq the child 
data flow diagram for 1.2 reveals the exact sensors used and 
the related data and commands. Examininq data flow diaqram 
1.2 (Fiqure 5-16) shows the details of what sensor processes 
exist. The operations break down into cateqories of qettinq 
sensor data and (in the case of gyros and FHST) processinq 
sensor commands. Similarly the interface between 1.3 MODEL 
ACTUATORS and 1.4 SIMULATE SPACECRAFT CONTROL can be charac- 
terized by operations that command actuators. Using these 
data flow interfaces we can begin to construct operation 
definitions for the TRUTH MODEL operations used by SPACECRAFT 
CONTROL. The operations provided by the other objects are 
derived in the same way as the TRUTH MODEL operations. 

These can then be combined into complete object descriptions. 
Fiqure 5-17 shows the complete object description for TRUTH 
MODEL. Note that we have also described the purpose of the 
TRUTH MODEL in Fiqure 5-17 to further document the object 
description. 

Adjustments can be made to objects and operations even at 
this late stage. For example we see on Fiqure 5-10 that the 
data flows "Ground Commands" and "Simulation Parameters" 
enter the SIMULATION RESULTS DATABASE from the USER 
INTERFACE. These data are also returned to the USER 
INTERFACE as part of "Simulation Results Data." We can move 

5-24 


0252 



2 MODEL SENSORS mm 



5-25 


Figure 5-16. 1.2 Model Sensors 










TRUTH-MODEL 


Purpose : 

This object simulates the "true response" of the space- 
craft to attitude control commands. It processes actua- 
tor commands, generates simulated sensor output and 
integrates the spacecraft attitude dynamics equations. 

It includes models of environmental perturbations and 
sensor measurement noise. 

Provides ; 

RESET ( ) 

I NITIALIZ E-PARAMETERS (TRUTH-MODEL-PARAMETERS) 

GET-GYRO-DATA () GYRO-STATUS + GYRO-DATA 
GET-FSS-DATA () FSS-STATUS + FSS-DATA 
GET-CSS-DATA () CSS-DATA 

GET-FHST-DATA () FHST-STATUS + FHST-DATA 
GET-TACH-DATA () TACH-DATA 
GET-TAM-DATA () TAM-DATA 

COMMAND-GYRO {GYRO-RATE-COMMAND ) 

COMMAND-FHST ( FHST-COMMAND) 

COMMAND-THRUSTERS (THRUSTER-COMMAND) 
COMMAND-REACTION-WHEELS (WHEEL-COMMAND) 

COMMAND-TORQUERS (TORQUER-COMMAND) 

Uses ; 

E2 STAR -CATALOG 
GET-STAR-DATA 

E3 EPHEMERIDES-FILE 
GET-EPHEMERIDES 

4 . 0 SIMULATION-PARAMETERS-DATABASE 
PUT-RESULTS-DATA 

5.0 SIMULATION-TIMER 
GET-TIME 


Figure 5-17. Truth Model Object Description 
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the appropriate parts of the data store D03 SIMULATION 
DATASTORE into the USER INTERFACE by updating the object 
contents table. The states OUTPUT SIMULATION PARAMETERS and 
OUTPUT GROUND COMMANDS are added to USER INTERFACE, and the 
contents of SIMULATION RESULTS DATABASE are updated to re- 
flect the removal of these data. The data dictionary is 
used to maintain consistency in defining states contained by 
an object, in the same way that the different levels of data 
flow diagram are used to define what processes are contained 
by an object. The actual change to data flow diagrams can 
be made when we start decomposing our objects. Figure 5-18 
shows the updated object contents table. 


user interface 
Processes: 

2.0 update Paraaeter Database 

3.0 update Ground OataDase 

4.0 Prepare Slauiatlon Results 
states; 

001 Paraaeter Oatabase 
004 Ground oatabase 

Output Slauiatlon paraaaters • Output Ground Coaaands 

spacecraft Control 
Processes: 

1.4 spacecraft control 
Svstea Considerations 

required as oDject to test control lavs 

pygca^ai 

1.1 Model Dynamics & Environment 

1.2 Model Sensors 

1.3 Model Actuators 
States 

002 Simulation Parameter Store 

State 

Sensor Data • Telemetry Doenllnk ♦ 

Dynamics Analysis Data * Actuator Analysis Data 

Timer 

Svstea Considerations 

Slaulator is required to Keep a slaulated tlae 


Figure 5-18. Updated Object Contents Table for GRODY 
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The last step in qeneratinq an object diaqram is to produce 
separate data flow diagrams for each object. These are used 
when the child object diaqrams are created. Fiqures 5-19 
and 5-20 show these diaqrams for USER INTERFACE and TRUTH 
MODEL, respectively. Note that these diaqrams are not 
merely the segments circled in Fiqure 5-10, but that they 
reflect the up-to-date object contents, as shown in Fiq- 
ure 5-17. The object SPACECRAFT CONTROL contains only 
process 1.4 SIMULATE SPACECRAFT CONTROL, which leaves the 
child data flow diaqram for process 1.4 as the startinq 
point for object identification. SIMULATION RESULTS DATABASE 
is a state that has no child object diaqram, thus no data 
flow diaqram is necessary for this object. If an object 
encapsulates a state, the data dictionary will qive the de- 
tails needed to complete the desiqn. If the data store on a 
data flow diaqram represents a more sophisticated data 
structure (such as a queue) a child object diaqram will have 
to be qenerated to show how the data structure is to be 
implemented and what operations can be performed. 

The TIMER object was qenerated from a non-functional re- 
quirement. As in the example of a data store representinq a 
queue, we have to use the operations identified to qenerate 
a child object diaqram. TIMER is simple enouqh to qenerate 
a child object diaqram directly from the knowledqe of what 
the operations are supposed to do. For a more complex ob- 
ject we would consider qeneratinq a specification for that 
object using data flow diaqrams before attemptinq a more 
detailed desiqn. 

5.3.4 GENERATING CHILD OBJECT DIAGRAMS 

The production of the TRUTH MODEL object diaqram will show 
how an object's operations provide a startinq point for the 
next level of desiqn. Fiqure 5-20 shows the processes and 
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A; Center of rtass • Geonagnetlc field 
in 8CS 

B: Vheel Angular nomentijn « 

Control Torque • Array and Antenna 
Angles 


Figure 5-20. Truth Model Data Flow Diagram 
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states contained by TRUTH MODEL. Since the sensors and ac- 
tuators (1.2 and 1.3) directly support the operations pro- 
vided to SPACECRAFT CONTROL by TRUTH MODEL the first step is 
to make these into entities and to make them the most senior 
entities within TRUTH MODEL, The orocess 1.1 MODEL DYNAMICS 
AND ENVIRONMENT clearly contains at least two entities, one 
to model the dynamics and one to model the environment. 

Thus we examine the child data flow diagram (Figure 5-21) to 
see what the next level provides in the way of entities. 
Process 1.1.2 COMPUTE ENVIRONMENTAL TORQUES is a process 
which models the effect of the ' spacecraft environment on 
attitude dynamics, and 1.1,4 MODEL INTERNAL MOTION models 
the effect of moving spacecraft parts on the attitude dy- 
namics. Thus combining 1.1.2, 1.1.3, and 1.1.4 into a single 
ATTITUDE DYNAMICS entity is a reasonable abstraction. 1.1.1 
COMPUTE EPHEM DEPENDENT PARAMETERS then becomes the 
SPACECRAFT ENVIRONMENT entity. 

To finish the entity araph we only need to decide whether 
the data store SIMULATION PARAMETER STORE should be divided 
among the already identified entities, or whether it should 
become an entity itself. We choose the latter and draw an 
entity graph (Figure 5-22) . This choice is opposite to what 
we did for DO 2 SIMULATION PARAMETER STORE when we generated 
the level 0 entity graph. Designers will make such changes 
in their approach as more details of the problem become 
apparent . 

In Figure 5-22, control flow is shown for the external enti- 
ties and the SIMULATION PARAMETER STORE entity. These enti- 
ties must show control flowing towards them since they 
contain data but no processing. In addition, the parent 
object diagram shows that SENSORS and ACTUATORS provide data 
as they are requested by the SPACECRAFT CONTROL. Thus, the 
SENSORS and ACTUATORS in turn need to request data to com- 
plete the actions required. Again, this is determined not 
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Figure 5-21. 1.1 Model Dynamics and Environment 





by the topoloqy of the entity qraph but by an overall desiqn 
strateqy. This leaves only the direction of control between 
SENSORS and ACTUATORS and between ATTITUDE DYNAMICS and 
SPACECRAFT ENVIRONMENT to be determined. In the latter case 
we make the SPACECRAFT ENVIRONMENT a junior object. This is 
because the dynamics modelinq is likely to chanqe from mis- 
sion to mission, while the environment does not chanqe. 

This will allow SPACECRAFT ENVIRONMENT to be implemented as 
a library unit and to be reused for subsequent missions. 

The SENSORS and ACTUATORS are combined into a sinqle ATTITUDE 
HARDWARE object. This is a qood abstraction, and it allows 
us to simplify the TRUTH MODEL desiqn and to defer consider- 
ation of the sensor/actuator interactions to the next level 
of detail. Fiqure 5-23 is the TRUTH MODEL object diaqram. 



Fiqure 5-22. Truth Model Entitv Graph 
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2,0 Spacecraft Ccxitrol 



Figure 5-23. Truth Model Object Diagram 

The object contents table and operations dictionary entries 
are generated in exactly the same way as for the level 0 
object diagram. The only difference is in how to start 
identifying the objects from a data flow diagram. 

5.3.5 TASKING CONSIDERATIONS 

In Section 3 we showed concurrency on an object diagram by 
having a single operation (e.g., RUN) flow into two or more 
objects. The same notation can be used on entity graphs. 

We thus have a means of representing concurrency on entity 
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graphs, but at this point we have not yet developed guide- 
lines for concurrency within our methodology. Cherry's 
[Cherry 85a] criteria for determining when an entity is con- 
current can also be used within the abstraction analysis 
model. In short, we have not imposed any rigorous guidelines 
about determining when objects are concurrent, but have a 
notation that is flexible enough to represent concurrency 
throughout the transition between specification and design. 
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SECTION 6 - CONCLUSION 


Object diagrams, abstraction analysis and associated prin- 
ciples provide a unified framework which encompasses con- 
cepts from several other methodologies [Yourdon 79, Booch 83, 
Cherry 85b] . The use of object diagrams and abstraction 
analysis provides the following: 

• A general object-oriented approach which handles 
system design from the top level, through object- 
oriented decomposition, down to a completely func- 
tional level. 

• A method of tracing how a design meets the specifi- 
cation . 

• A design notation that maps into Ada, thus provid- 
ing a composite mapping from a specification to Ada 
software . 

• A design notation flexible enough to represent both 
traditional structured designs and non-hierarchical 
designs such as those produced using PAMELA. 

• Criteria for partitioning a software system into 
modules and for choosing direction of control. 

• Support for walkthroughs and iterative refinement 
of a design through the use of graphical notation 
for both the specification and the design. 

The concepts discussed in this report form an integral part 
of an object-oriented software development life cycle. We 
are currently studying how object-oriented concepts can be 
used in other phases of the life cycle, such as specification 
and testing. When complete, this synthesis should produce a 
truly general object-oriented development methodology. 
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